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Certain documents cited 
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I. Basis of the report 

1 . With regard to the elements of the international application (Replacement sheets which have been furnished to 
the receiving Office in response to an invitation under Article 14 are referred to In this report as "originally filed" 
and are not annexed to this report since they do not contain amendments (Rules 70. 16 and 70.17)): 



Description, Pages 

1 , 2, 4-1 5 as originally filed 

3, 3a received on 21 .04.2005 with letter of 1 6.04.2005 
Claims, Numbers 

1-16 received on 21 .04.2005 with letter of 1 5.04.2005 
Drawings, Sheets 

1>9-9/9 as originally filed 

2. With regard to the language, all the elements marked above were available or furnished to this Authority in the 
language in which the international application was filed, unless othenwise indicated under this item. 

These elements were available or furnished to this Authority in the following language: , which is: 

□ the language of a translation furnished for the purposes of the international search (under Rule 23.1 (b)). 

□ the language of publication of the international application (under Rule 48.3(b)). 

□ the language of a translation furnished for the purposes of international preliminary examination (under 
Rule 55.2 and/or 55.3). 

3. With regard to any nucleotide and/or amino acid sequence disclosed in the international application, the 
international preliminary examination was carried out on the basis of the sequence listing: 

□ contained in the international application in written form. 

□ filed together with the international application in computer readable form. 

□ furnished subsequently to this Authority in written form. 

□ furnished subsequently to this Authority in computer readable form. 

□ The statement that the subsequently furnished written sequence listing does not go beyond the disclosure 
in the international application as filed has been furnished. 

□ The statement that the information recorded in computer readable form is identical to the written sequence 
listing has been furnished. 

4. The amendments have resulted in the cancellation of: 

□ the description, pages: 

13 the claims, Nos.: 17-20 

□ the drawings, sheets: 
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5. □ This report has been established as if (some of) the amendments had not been made, since they have 

been considered to go beyond the disclosure as filed (Rule 70.2(c)). 

(Any replacement sheet containing sucli amendments must be referred to under item 1 and annexed to this 
report.) 

» 

6. Additional observations, if necessary: 



V. Reasoned statement under Article 35(2) with regard to novelty, inventive step or Industrial applicability: 
citations and explanations supporting such statement 



1. Statement 
Novelty (N) 



Inventive step (IS) 



Industrial applicability (lA) 



Yes: Claims 

No: Claims 

Yes: Claims 

No: Claims 

Yes: Claims 

No: Claims 



1-16 



1-16 



1-16 



2. Citations and explanations 
see separate sheet 
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1 . The invention discloses a method (Independent claim 7) for authenticating clients 
in a client-server environment, wherein said client-server environment uses a 
communication protocol that allows extensions of the header request without violating 
said communication protocol, wherein a system establishes communication between 
said client and said server, wherein said system comprises the steps of: receiving a 
header request from said client, inserting authentication information into said header 
request resulting In an extended header request Independently of the authentication 
process used by said server and without server requesting authentication information, 
sending said extended header request to a server and receiving infonnation from said 
server if the authentication has been successful. The corresponding method 
implemented at the client-side (Independent claim 1), the corresponding method 
implemented at the sen/er-side (independent claim 10) and the corresponding 
aetver system (independent claim 12), client system (independent claim 13) and 
proxy server system (independent claim 15) are also disclosed. 

2. Such methods and systems are disclosed in the closest prior art D1= 
US2002/0 133700. 

2.1 The difference between the document D1 and the invention is the following: 

The Inserted authentication information comprises the client certificate containing 
client's name and client's public key, and a digital signature which has been 
generated over the whole header request Including client certificate using client's 
private key. 

2.2 The problem solved by such a technical feature is how to ensure that the client is 
securely authenticated without the need of a secure protocol like SSL. More 
specifically how to ensure that the request header arriving at the server has not been 
tampered with on the way from the client to the server. 

2.3 D1 discloses a method and a device for sending a certificate from a client to a 
server by inserting a certificate into a cookie header of a request in HTTP or 
equivalent protocol. D1 does not give any hint about how to ensure that the client is 
the authenticated owner of the certificate. The present solution consists then in 
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providing a digital signature generated over a hash value of the request header with 
the client's name and client's public key as the authentication information to be 
inserted in the header request. 

3. The dependent claims 2-6, 8, 9, 11, 12, 14, 16 add further features to the subject- 
matter of the claims they depend on, and are therefore based on the same inventive 
concept. 

4. Therefore claims 1-16 are new and inventive. 
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modifications on the server side as well as the client side, 
e.g, additional card reader with specific security applications. 
Therefore, such implementations cause much effort on costs and 
time with the consequences that preferably only new client- 
server infrastructures will be using the digital signature 
procedure. The existence of those two authentication procedures 
in the client-server environment has the disadvantage that a 
client has to check at first whether the destination server is 
supporting the password logon or the digital signature 
procedure. Depending on that result the client will use the 
required authentication process supported by the server. It 
causes much unnecessary network traffic between client and 
server since the server application itself finally determines 
the type of authentication. 

Furthermore, the present digital signature authentication 
procedures have the disadvantage that several screens between 
client and server have to be exchanged between client and server 
until the client can provide its authentication information. 
This causes much unnecessary network traffic. 

US2002/0133700 Al discloses a method and system for 
communicating a certificate between a security module and a 
server. The problem posed by the present invention is the lack 
of means for communicating a certificate from a client between a 
security module and a server, the protocol used between the 
client and the server being HTTP or an equivalent protocol, a 
security protocol like SSL or an equivalent protocol being 
implemented between the client and the security module. 
It offers a method and a device for communicating said 
certificate from the module to the server, which consists of 
inserting said certificate into a cookie header of a request in 
HTTP or an equivalent protocol sent by the client. 
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Object of the invention 

Starting from this, the object of the present invention is to 
provide a method and system for authenticating clients in a 
client-server enviroxnnent by avoiding the disadvantages of the 
cibove-mentioned prior art. 

Brief summary of the invention 

The idea of the present invention is to replace the existing 
password/user ID based authentication process by a new digital 
- signature authentication process in which preferably the first 
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1. Method for authenticating clients in a client-server 
environment, wherein said client-searver environment uses a 
communication protocol that allows extensions of the header 
request without violating said communication protocol, wherein 
client comprises the steps of: 



generating a header request (10), 



inserting client authentication information into said header 
request resulting in an extended header request (20) 
• independently of the authentication process used by said searver 
and without server requesting authentication information, 
wherein said authentication information comprises the client 
certificate containing client's name and client public key, and 
a digital signature which has been generated over a hash value 
of the header request including client certificate using Client 
private key, 

sending said extended header request to a seirver (30) , 

and receiving information from said server if authentication has 
been successful (35,60). 

2. Method according to claim 1, wherein said communication 
protocol is a HTTP-protocol. 

3. Method according to claim 1, wherein said authentication 
information is included in the first header request for 
establishing a session with said server. 

4. Method according to claim 1, wherein said authentication 
information is automatically inserted into said header request 
by the Client's browser. 

■ 

5. Method according to claim 4, wherein said client browser 
receives said authentication information from a smart card (10) 
via a smart card reader. 
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6. Method according to claim 1, wherein said authentication 
information is automatically inserted into said header request 
by a client signature component (20) which receives said 
authentication information from a smart card (10) via a smart 
card reader. 



7. Method for authenticating clients (la, lb) in a client-server 
environment, wherein said client-server environment uses a 
communication protocol that allows extensions of the header 
request without violating said communication protocol, wherein a 
system (22) establishes commimication between said client (la, 
lb) and said server (3), wherein said system(22) comprises the 
.. steps of: 



receiving a header request from said client (la, lb) , 

inserting authentication information into said header request 
resulting in an extended header request (20) independently of the 
authentication process used by said server and without server 
requesting authentication information, wherein said 
authentication information comprises the client certificate 
containing client's name and client's public key, and a digital 
signature which has been generated over the whole header request 
including client certificate using Client's private key, 

sending said extended header request to a server (3), and 

receiving information from said server (3), if the 
authentication has been successful. 

8. Method according to claim 7, wherein said system (20) can be 
a proxy server, a gateway, or a ttinnel. 

9 • Method according to claim 7 , wherein said communication 
protocol is the HTTP-protocol, and said authentication 
information is automatically inserted into said HTTP-reciuest 
header by said an insertion component (20) which receives said 
authentication information from a signature component (24) • 
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10. Method for authenticating clients in a client-server 
environment, wherein said client-server environment uses a 
communication protocol that allows extensions of the header 
request without violating said communication protocol, wherein 
at said sejTver side said method comprises the steps of: 

receiving a client header request containing authentication 
information, wherein said authentication information comprises 
the client certificate containing client's name and client's 
public key, and a digital signature which has been generated 
over the whole header request including client certificate using 
Client's private key, 

validating said authentication information contained in said 
header request by said- server authentication component, and 

providing information to said client, if the authentication has 
been successful. 



11. Method according to claim 10, wherein said communication 
protocol is the HTTP-protocol, and said authentication component 
perfoincns the steps of: 

accessing said public key contained in the client certificate, 
decrirpting said digital signature contained in the HTTP-request 
header with said public key resulting in a hash value, 
applying the same hash algorithm as used by said client to said 
HTTP -request header, and 

considering authentication as successful, if both hash values 
match . 

12. Server System (3) for authenticating clients (1) in a 
client-service environment, wherein said client-server 
environment uses a communication protocol that allows extensions 
of the header request without violating said communication 
protocol, wherein said client (1) provides authentication 
information in the header request to said seirver system, wherein 
said server system (3) comprising: 
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an authentication component (4) with the functionality to read 
said authentication information contained in the incoming client 
header request, wherein said authentication information 
comprises the client certificate containing client's name and 
client's public key, and a digital signat\ire which has been 
generated over the whole header request including client 
certificate using Client's private key, and to validate said 
authentication information without having requested said 
authentication information from said client. 

13. Client System (1) to be authenticated by a server system in 
client-server environment, wherein said client-server 
. environment uses a communication protocol that allows extensions 
of the header request without violating said communication 
protocol, wherein said client system comprising: 

a browser (2) , and 



a component for inserting client authentication information into 
said header request independently of the authentication process 
used by said server and without server requesting authentication 
information, wherein said authentication information coittprises 
the client certificate containing client's name and client's 
public key, and a digital signature which has been generated 
over the hash value of the header request content using client's 
private key. 

14. Client System according to claim 13, further comprising 
a smart card reader (10), and 

a smart card (10) with a security module containing client's 
private key and a client certificate containing client name and 
private key, wherein said smart card provides said certificate 
together with a digital signature to said inserting component, 
wherein said digital signatxire is the result of an encryption of 
a hash value of said header request containing said certificate 
information by means of said private key. 

* 

15. Proxy Server system (22) for providing client authentication 
information to a server systsn (3), wherein said pro3c/ server 
system (22) has a communication connection with a client system 
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{la, lb) and a server system (3), wherein said communication 
protocol used between said systems allows extensions of the 
header request of said header request without violating said 
communication protocol, wherein said proxy server system (22) 
comprising: 

a proxy insertion component (20) for inserting the client 
certificate and digital signature into the header request 
received from said client independently of the authentication 
process used by said server and without seirver requesting 
authentication information, and 

. a signature component (24) for creating a digital signature and 
for providing it together with said client certificate to said 
proxy insertion component (20) . 

16- Computer program product stored in the internal memory of a 
digital computer, containing parts of software code to execute 
the method in accordance with claim 1-11 if the product is rim 
on the computer. 



